Case Study: Large Video Game Product Development

1,230 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,230
On SlideShare
0
From Embeds
0
Number of Embeds
9
Actions
Shares
0
Downloads
16
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Case Study: Large Video Game Product Development

  1. 1. 1! LARGE VIDEO GAME (LVG Inc.) PRODUCT DEVELOPMENT CASE STUDY Executive Overview This is a story of an organization within the video game industry where the content and execution of product development has been in the throes of fundamental change, and particularly, is increasingly accomplished with virtual teams of geographically dispersed members, partners and contractors. While the richness of talent across the globe and the hope for lower development costs is enticing, the prospect of increased difficulty in the development process due to uncertainty and miscommunication is greater when team members are not co-located. Therefore, it is notable how the organization featured in this case study has achieved excellent results for late-stage development and scale-up of assets through effective standardization of outsourced work with contractors. However, the organization has also found virtual organization for an earlier stage of product development, when product outcome and processes are less definable, to be more problematic. Nevertheless, through some exemplary organizational learning, this company has innovated in its project planning and other coordination mechanisms to overcome many of the barriers at this earlier stage of engineering and product development. This case confirms findings from earlier studies as to how the most critical coordination mechanisms for successful product development in a virtual organization differ, based on the level of uncertainty and ambiguity inherent to the specific project (stage). The study also highlights how the dynamic nature of a business such as video gaming requires continual adaptation in design of the virtual organization for product development. And, effective coordination of such virtual organization depends upon a ‘socio-technical’ framework that includes a robust combination of organizational, interpersonal, work process, and IT solutions. Context Recently, computer games have come to be developed with teams distributed around the world. Individuals involved in developing a game no longer sit side by side. Team members and contractors are in far flung corners of the globe. But it was not always this way. The very first primitive computer game “Tennis for Two”, was created on an oscilloscope- like instrument in 1958 by one scientist in his lab.1 A few years later, fewer than 5 individuals in a lab at MIT created a two-player game called “Spacewar”, run on a computer when computers cost more than $150k and were only found on campuses and national laboratories. As computer technology advanced so did the development of computer games. In 1980, Pac Man, created by a team of 9, came to market for play on video arcade game machines. With the release of Apple 2, Commodore 64 and other early computers, people could afford to buy such devices to play video games in their homes and the industry began to boom in the 1990’s, considered by some, as the golden age of computer video games. Co-located teams developed all of the games created during these years.2 1 Anderson, John, Creating Computing Video & Arcade Games Vol.1, No.1, Spring 1983, p. 8 2 Graetz, J.M., Creative Computing Magazine, August 1981
  2. 2. In the early 2000’s, Microsoft entered the market of game consoles with the X Box and Sony with the Play Station Portable. The technology continued to advance powerfully allowing for far more complexity in the games in terms of look and play. Teams were now in the neighborhood of 50 people and still co-located. In 2005 there was a large jump in technology and the Xbox 360 and Sony’s PSP, Play Station 3, were released which significantly increased the burden on game developers who sought to take advantage of the new level of complexity for play and graphics. Increasing complexity even further, simultaneously games were expanding to online play as well. Team size increased to well beyond 100 team members. Equally relevant, the cost to develop a game increased from US$1M-4M in 2000 to over $5M in 2006 to over $20M in 2010. The computer game industry was energetically working to find talent needed to develop these increasingly complex games and simultaneously concerned about the seemingly ever-increasing cost of development. As the pressure to lower development costs and take advantage of talent positioned around the world increased, the industry began in earnest to learn how to develop video games virtually. It is interesting to note that in comparison to the film industry, software engineering, or other forms of digitized work, the video game industry lagged far behind in virtualization of product development. Case Study Project & Site Background This case study describes one video game team’s early efforts to develop a new release of a long running game series with a geographically distributed virtual organization. The product, GAME X 1, developed in the period of June 2010 to June 2011, at a cost of $12 million, was the primary focus of our study with some opportunity to follow-up on the early stages of GAME X 2 (June 2011 to June 2012).3 The Game X series is one of the franchise labels, within a division of Large Video Game Inc. (LVG Inc.), headquartered in the United States. Each year a new version of the game is developed and released to coincide with a seasonal pattern of recreation in North America. The game is configured for 2 console platforms, X-Box 360 and PlayStation3, along with a website to support increasing web-based consumer interactivity with the game. The product development process for GAME X is very critically time-bound through the utilization of ‘Agile’, a development process characterized by rapid prototyping and multiple iterations to game feature completion. Iterations are organized in 13 three-week ‘Sprint’ cycles to accomplish, in the case of GAME X 1, development of 30 major new features (e.g. 3D elements) and minor features (e.g. animated characters) within an overall total of 1000 new game features. Process stages include Concept Discovery, Design & Planning, First Production and Final Production, intense Testing and De-Bugging, and Shippable Build of the product for Delivery. The GAME X 1 team was comprised of a co-located core team, some team members distributed throughout North America and any number of other contractors located around the world. The vast majority of the design and development of this game was done by the core team, located in a studio in the United States. The organization structure for GAME X’s “franchise” core team had 3 See Appendix 1: Methodology
  3. 3. 3! a Project Leader to whom reported Art and Technical Directors and a Program Manager who oversaw Development Managers and Character Modelers, Technicians and System Engineers for each of the Art, Audio, and Engineering components of the game. Production included Art Assets (e.g. 3D animated figures, photo realistic heads of game characters), Audio Assets (e.g. music, voice-over commentary), and Engineering (e.g. new and revised programming for the source code of the game or for the server code connecting the game and its website, or for a new feature of the interactive website like the ability to recruit characters to one’s play of the game). Funded by a grant from the National Science Foundation, our study of LVG Inc. has utilized socio-technical systems (“STS”) analysis of R&D work organization to reveal the influence of virtuality on the quality of deliberations/key conversations and related knowledge development barriers involved in the ‘outsourced’ development of specific elements of the Game X product. Within our overall NSF research, this LVG study is one in a sample of three comparative case studies of ongoing virtual research and development projects, each situated at a different stage in the continuum of the R & D process (see Fig.1.) One project represents pure fundamental research (“R1” on the continuum) by physicists around the world. A second project involves primarily advanced development (stage “D2”) of a uniform data set by medical centers across the United States. We have characterized this R & D continuum as an intrinsic learning system with multiple stages. Each stage is defined by the degree to which participants do or do not know the “what” (objective end state) of their work or the “how” of their knowledge development and synthesizing activities.4 The development work of Game X involved some Start-Up Development (D3) but mostly Scale- Up Development (D4) activities meaning, that for the team, to a large extent in their work activities, both what they were to do and how they were going to accomplish it was relatively clear. Almost all of the outsourced development of art assets was of a “D4” type and much of the outsourced Engineering and Website development was of a “D3” type. 4 Bell Labs’ R&D Portfolio Management profile, as reported by John Mashey to Andrew Revkin (NY Times, December 12, 2008), and adapted by Carolyn Ordowich. !"#$% &$'$(#)*% +,#-% !"#$%&'#"(& %+./0%% )*&+,*& -../012&3.,& !"#$%&'#"(&& .1+%% 4.&5+,,6&.74& 48*&,*9*+,58& /2234$5% &$'$(#)*% +,#-%% !"#$%&'#"(&& +./0% :0;*;&*1<&94+4*& .,&.=>*5?@*A& '#"(& %.1+%% 4.&5+,,6&.74& 48*&,*9*+,58& 6723,#(8,#9% :$;$3,2<$=8% +,#-% '#"(& %+./0%% !"#$%&'#"(& &.1+% &4.&+580*@*&04& /5;(=)$5% :$;$3,2<$=8% +,#-% '#"(&& +./0% !"#$%&'#"(&& .1+%>?% :60/>@%% 4.&+580*@*&04& A8(#8BC2%%% :B0-.4&B-+149C&& =*4+&4*9?12A& :$;$3,2<$=8% +,#-&! '#"(&& +./0% '#"(&& .1+% D1?D6!0C/@@E% 4.&+580*@*&04&& A)(3$BC2% :@.-7D*&E& 5.949A& :$;$3,2<$=8% +,#-%& '#"(&& +./0% '#"(&& .1+% 1!6&/0>1?/@@E% 4.&+580*@*&04& R 1 R 2 D 1 D 4 D 2 D 3 FGHF&I15*,4+0146& J"(KL&I15*,4+0146& M027,*NO&&P0QRP4+2*&S.1?177D&.3&48*&LE!&T,.5*99& !"#$%&'()*&+',#-&.'"#$%&'(!
  4. 4. While the game team had prior experience working with virtual organizations, they were still relative novices in terms of dispersed development and certainly very new to attempting to work virtually on the engineering aspect of game development. Comparable to the rest of the industry, until a very few years ago as described earlier, all of the product development in the division was done in-studio, co-located. Now, however, there was a corporate mandate to increase outsourcing to 20% of Artwork (hours) and 10% of Engineering. Similarly, as mentioned earlier, as development costs skyrocketed, much of the drive for outsourcing is cost reduction (i.e. artwork by Asian vendors is a third to a seventh of US cost, and even Quality Assurance/Testing is 50% cheaper if outsourced to lower cost locations within the USA). Perhaps not surprisingly, among the studio staff, some fear exists regarding outsourcing. No doubt, there is some anxiety about outsourcing ‘our own jobs’. Further, this team has enormous pride in their game and its history and the quality of outsourced work is of concern. Generally, there is a view that “creative” work should happen internally. The current LVG Inc.’s mantra is that, if the work is “fun, and if LVG wants to or has to maintain the capability or technology, keep it in-house.” Beyond outsourcing the routine, non-creative work such as repetitive artwork there is perceived value specifically in outsourcing to access special talent (e.g. interactive web design) that is not a capability readily available in-house. There is also the perspective that the more that some work (e.g. QA/Test work) can be outsourced, the more it frees up internal staff to focus on higher value work (e.g. prevention, versus detection, of game “bugs”). The Virtual Partners For the GAME X 1 project, there were 3 major Art asset vendors, one located in the Philippines, one in China, and another in India, each producing a different type of art asset, requiring in most (but not all) cases fairly routine execution. These overseas vendors are not small-sized enterprises—they are world-class facilities serving global clients. For the Art assets, the vendor Lead Artist was known by and in direct communication with LVG, but not the actual Artist (s), while LVG was represented by an Outsourcing Manager and an Art Development Manager for contract negotiations, and by a GAME X 1 Lead Artist/Modeler for execution of each specific art assets. In earlier versions of the game, engineering tasks have been outsourced to a vendor in Argentina, and website development had been outsourced within the United States. However, for GAME X 1, Engineering outsourcing was limited to 2 vendors located within close proximity, with a later addition of a 3rd vendor based in northern Europe, all of whom worked on aspects of the interactive website/online version of the game. One of the locally based Engineering vendors is operated by a small number of ex-studio employees. This company has been viewed by the LVG Inc. as a very competent, reliable vendor who is familiar with the Corporation’s development processes. The second locally based Web outsourcing vendor is located almost next door to the studio, though this company is new to video gaming and LVG Inc. In both these examples of Engineering outsourcing, the primary communication occurred between 3-5 people at the vendor and 1-2 System Engineers and 1 Manager for the Online Development team in the ‘GAME X 1 project.
  5. 5. 5! The GAME X 1 project had one other major remote organization, with whom they worked, a test center for outsourcing of Quality Assurance. A few years ago, the Corporation motivated to some extent by financial incentives from a particular state, created an organization located on a university campus that could access a part-time work force to test the game. This remote QA organization supplemented the in-process (“embedded”) QA function within each of GAME X’s development teams, and was mainly employed during the later phases of the project for final Testing/De-Bugging. Approximately 60% of the overall QA work was outsourced to this vendor where students hired on short-term contracts perform the actual testing for 85% of all of LVG’S products worldwide. Deliberations Deliberations/key conversations are a critical aspect of non-routine/knowledge work.5 In product development, deliberations are understood as social interactions in which knowledge is discussed, generated and/or exchanged to reduce uncertainty about a particular topic- define or solve a problem, make a decision, or implement a solution etc. Typically these interactions are sense- making exchanges, communications and reflections in which many people engage. Throughout the development process, deliberations are on-going and never ending. In essence, the deliberations/key conversations are the turning points in the knowledge work process that allow work to move forward. In terms of the R & D continuum, most of the work within the virtual components of GAME X 1, especially production of art assets, has been ‘D4’ development work. The core team knows ‘what’ they want developed (with very clear specifications) and they know ‘how’ it can be achieved operationally through prototypes they have built. The art vendors describe their work as ‘routine’ or ‘routine with a minor degree of discretion.’ Basically, the vendors need to very closely replicate the specified art assets working from the prototypes. On the other hand, “D3” development occurs with more of the systems engineering and website work, where the core team knows ‘what’ they want to have developed but their expertise is limited to ‘knowing conceptually how’ to achieve these outcomes. Engineering and website vendors describe the work they are contracted to develop as ‘routine, but requiring discretion’ or ‘non-routine, with moderate degrees of freedom’ and in one instance, a vendor felt he had a ‘high amount of discretion’. Nevertheless, the key deliberations involving GAME X 1 staff and external vendors for virtual Art Production are very similar for virtual Engineering and Web/online game development; namely, they are key ‘choice points’ that occur in the front-end of the development process. For example, ‘vendor selection’ is a deliberation topic of primary significance in all these aspects of game development. The GAME X 1 staff found another key deliberation topic to be ‘defining and estimating’ the outsourced project work. And, a third key deliberation specifies ‘documentation and requirements’. 5 Pava, Calvin, Managing New Office Technology, The Free Press, New York, N.Y., 1983, p.58
  6. 6. The core team’s focus on these key deliberations is aligned with our understanding of the R & D continuum. Given GAME X’s development work falls in the ‘D3-D4’ range, clarity on both ‘know what’ and ‘know how’ is crucial to successful development. The drive at this end of the R & D continuum is for clarity and specificity between the core team, dispersed members of the team and vendors to facilitate speed to market, higher quality and lower costs. Knowledge Development Barriers/Challenges With respect to knowledge development barriers/challenges that could disrupt, delay, or detract from the quality of deliberations associated with GAME X product development, the differences between the experience of virtual Art Production and virtual Engineering or Website development are very illuminating. For virtual art production, (i.e. “D4” development work), during both generations of video game development Game X 1 and GAME X 2, the occurrence of key knowledge barriers in these deliberations was much less evident than in all of the other development work conducted through virtual organization. Despite ‘far-flung’ locations of Art Asset vendors in parts of Asia very distant from the core LVG Inc. operation, potential limiting factors of time zone, language and national culture differences, all proved to be insignificant barriers to sharing or utilizing knowledge in key deliberations about expectations and requirements for Art Production. On the other hand, for virtual Engineering and Web/Online systems, (i.e. “D3” development work), significant barriers did arise, particularly for the earlier version of the product development, GAME X 1 observed in this study. Issues included unclear expectations, lack of clear decision making, unrealistic timeframes, delayed data transfer, and lack of documentation. Due to IP issues about game source code, the core team could not share vital source code with vendors. The inability to share code caused significant barriers in knowledge-sharing in systems Engineering. For “D3” type web development, lack of planning and clear decision making internal to the core team and LVG, meant that expectations about requirements quite often diverged and were not always effectively resolved between LVG Inc. and vendors. In deliberations about the selection of web development vendors, there was also an initial failure to utilize knowledge that other divisions of LVG Inc. had about reliable capabilities and technical set-up in companies distributed across the vendor community. Knowledge barriers associated with different frames of reference also affected Quality Assurance. Although the remote test center and LVG Inc. core operations are part of the same company, their respective staff had different understandings about the ‘speed’ or pace expected for work completion. Also, part-time and high turnover Testers at the remote test center did not have access to the ‘tacit’ knowledge held by GAME X 1’s core team regarding critical features of the game architecture. Consequently, some high severity game “bugs” were not initially tested, though the core team prior to final product delivery eventually discovered and corrected them.
  7. 7. 7! Coordinating Mechanisms and Improvements Year Over Year In conjunction with what our study found about the existence or non-existence of knowledge development barriers in different aspects of GAME X 1’s product development, there was also evidence of how various coordination mechanisms have forestalled or were introduced to overcome such barriers in the virtual work involving LVG Inc. and its vendors. And, these findings are consistent with prior research and organizational theory that has established the need for coordination mechanisms to handle the amount and richness of information processing by/for/among team members, as required by the varying degree of uncertainty and ambiguity inherent in a team’s task and its relationships.6 Coordinating mechanisms make a major difference in how well deliberations in non-routine work incorporate the right information and knowledge, and the right participants at the right time. Our study focused on a continuum of four main types of coordination mechanisms often cited in information systems literature: (1) standards; (2) plans; (3) formal mutual adjustment; and (4) informal mutual adjustment. Coordination through “standards” and “plans” relies upon pre-specification of rules, routines, techniques, and targets. Both are mostly impersonal in nature once implemented and facilitate task completion/the technical side of the organization. In contrast, both forms of “mutual adjustment” appear to be coordinated through interpersonal communication, feedback and interaction, some “more structured and formalized” through design review meetings or liaison roles, while other adjustment mechanism rely upon the “informality” of impromptu or face-to- face communication. 6 Daft & Lengel, 1986, Organizational Information Requirements: Media Richness and Structural Design, Management Science, 32, 4, pp. 554-571. Galbraith, J., 1974, Organization Design: An Information Processing View, Interfaces, 4, 3, pp. 28-36.
  8. 8. In addition to defining these key modes of coordination, research has suggested that where the project sits on the R & D continuum is a key determinant of the suitability or requirement for specific coordination mechanisms. In broad terms, the research indicates that “more informal, communications-oriented” mechanisms are more suitable “when uncertainty is greater, during the requirements analysis phase”. On the other hand, more impersonal, “more formal, control- oriented” mechanisms are “most suitable when uncertainty is less during the design, implementation, and testing phases of a project”.7 Indeed, the experience of virtual product development for GAME X confirms these patterns identified by prior research (see Table 2). For example, the relatively routine and mature work processes of virtual Art Production (‘D4’ stage of product development) enable clear expectations for both LVG Inc. and its vendors, almost eliminating any ambiguity in terms of “what good looks like” in task deliverables. Key deliberations in virtual Art Production can therefore involve the parties’ gaining shared agreement on “standardization of outputs”, through communication in “rich” media of screen shots, visual targets, emails, and extensive digital documentation. However, for Engineering and Web/Online game development, LVG Inc. staff most often do not know the details of ‘how’ the outputs are to be achieved. Moreover, the quick feedback that is possible when co-located, standing over each other’s computers and making ‘live’ corrections to 7 Sabherwal, R., 2003, The Evolution of Coordination in Outsourced Software Development projects, Information and Organization, 13 (3), pp. 153-202. !""#$%&'("&)!'*+,"#-) !""#$%&'("&)*+) ./012032.) !""#$%&'("&)*+) 4501.) !""#$%&'("&)*+) 673805)) 89/905) 02:9./8;1/) !""#$%&'("&)*+) <1673805)) 89/905) 02:9./8;1/) !'=+);>'?@A+=)) 4B#+)3+=+'#CD)) 3E) 0$F'&C+$) 2+F+A"@?+&*) 2G)))))2HI2J) 2H))))))))))2J) • ,%-.)%&/0.1("&23.#%41'("&) • 5%.#'#16+23.#(1'7)1"889&%1'("&) • :"#8'7)8..(&;/2/-'-9/)#.3%.<) • ,-..#%&;)1"88%=../) • >.?.#.&-)"#;'&%@'("&) • :'1%7%-'-"#2AB.-<"#C)D9%7$.#E)#"7.) • F%'%/"&2E,-#'$$7.#E)#"7.) Table 2: Most Significant Coordination Mechanisms in Case Study Virtual R&D Projects • G.7%3.#+)/16.$97./) • H#"I.1-)8%7./-"&./) • >.J9%#.8.&-)/0.1%41'("&/) • ,%;&K"L/) • :%&'&1%'7)%&1.&(3./) • !"80.77%&;)A8%//%"&E2;"'7) K) K) K) K) K) K) K) K) • M9-09-),-'&$'#$%@'("&N0#"-"-+0.O) /1#..&)/6"-/O)3%/9'7)-'#;.-/) • ,C%77/),-'&$'#$%@'("&2-#'%&%&;) • ,-'&$'#$%@'("&)"?)H#"1.//./) • G%';&"/(1)%&/-#98.&-/) • G'-')?"#8'-/) • P##"#K-#'1C%&;)0#"1.$9#./) K) K) K) K) K) K) K) • Q80#"80-9)1"889&%1'("&) • Q&?"#8'7)8..(&;/) • !"&?.#.&1./O)<"#C/6"0/) • ,%-.)3%/%-/) • R.80"#'#+)1"K7"1'("&) K) K) K) K) K) K) K) K) K) K) K) K) K) K) K) K) K) K) K) K) K) K) K) K)
  9. 9. 9! any misunderstandings or other knowledge frame of reference issues has thus far, proved to be unavailable with Engineering vendors in a virtual organization. This problematic situation resulted in delay and cost overruns for GAME X1, the first of the two product versions of game development that we observed in this study of LVG Inc. The GAME X franchise team and LVG Inc. are rightfully very proud of the game they produce annually. Highly rated in terms of innovation and quality, the game also produces a great deal of revenue for LVG Inc. Not surprisingly, therefore, the GAME X core team proved to be relentless in their quest for continued innovation in game play and product development. Once GAME X 1 was shipped, a post mortem/development review was undertaken per the franchise’s annual practice. Barriers in the development process were identified and ‘fixes’/coordinating mechanisms were implemented for GAME X 2. Starting with vendor selection, deliberations are now coordinated between the Game X franchise team and representatives from other divisions of the company to pool all available ‘intelligence’ about potential vendors. There is now on-site verification by LVG Inc. to ensure vendors have the proper technical set-up before any selection is made. New technical arrangements have also helped overcome the intellectual property issues that previously constrained the sharing of game source code with Engineering vendors--a “cloud-based desktop” solution provides vendors access to source code and the ability to integrate new code, while preserving LVG Inc. proprietary control. Furthermore, to reduce barriers related to expectations and realism of timeframes for Engineering and Website projects, the Game X team now requires its staff to develop more robust plans clarifying project scope before any vendor contractual negotiations. Projects are also “chunked” into phases, and vendors must provide schedules for specific deliverables. Finally, to facilitate decision making, timeliness, availability, and consistency of participation by Game X staff in deliberations with Engineering vendors throughout the development process, the Game X team has made a structural role change to designate a single “product owner” assigned to resolve issues for each vendor for a specific engineering assignment. The new role requires staff with a solid combination of technical and project management skills. With respect to the issues in Quality Assurance work, the post mortem/development review proposed numerous steps to close the gaps in knowledge coordination. The Lead Tester at the remote test center was to have a closer liaison role with Game X core operations. The Test Lead would also reinforce LVG Inc.’s increased Tester training (i.e. “standardization of skills”). At the same time, work processes at the remote test center were standardized through greater use of audited test scripts. Finally, the Game X team aimed to increase the “ownership” and tacit knowledge of the remote Testers by enabling them to videoconference into production meetings and ‘scrums’ at Game X’s core team meetings and thus, learn about new game features and their potential issues/priorities for beta testing. Given many of these changes in coordination of the product development process, (see Table 1), significant barriers to sharing and utilizing knowledge with Engineering and Website vendors were eliminated or reduced. Consequently, for the second product run, GAME X 2 was completed on-time, on-spec, with less quality issues, and on-budget.
  10. 10. Final Words As with almost every other industry, video game development is constantly evolving, partly due to new development technology including new game platforms, and substantially due to a consumer demand for more interactive online gaming. The industry is now moving to all digital products that continually deliver new twists and turns to delight a consumer who wants access to games 24/7 with his/her mobile devices. There is a strong likelihood this product transformation will vastly increase requirements for game content (for example, as consumers desire to draw upon a ‘library’ of art assets to create their own costumes for game characters). Meanwhile, development technology will likely also evolve so that vendors will have the ability to integrate their artwork directly into the larger game as a company such as LVG INC is developing it. The art development process may come to resemble a ‘Hollywood’ model with ongoing critiques of a vendor’s work like a movie director’s review of ‘dailies’, so that the video game artist in a virtual product development organization takes on a role more like a mini art director. Suddenly, the old days of co-located product development teams with 12 months to develop a new game release look idyllic. The story of the Franchise team in LVG Inc. that we had the pleasure to follow for several years is still being written. What type of coordination mechanisms will be implemented to support their needs for constant development through collaboration at a distance have yet to be identified and implemented. In general, however, our findings indicate that identifying the nature and location of their virtual product development work on the R&D continuum can help practitioners to anticipate the general degree of their coordination challenge and the type of coordination mechanisms that are likely to be most critical to success. Then, analysis of deliberations and of potential or actual knowledge development barriers can provide detailed insights to inform the project-specific design of coordination. Finally, the evidence from this case study (see Table 2) and from other research is that the choice of coordination mechanisms for virtual product development should include a ‘socio-technical’ mix of organizational roles and structures, individual skills, specific work processes, and requisite IT solutions. References Anderson, John, Creating Computing Video & Arcade Games Vol.1, No.1, Spring 1983, p. 8 Daft, R. L., Lengel, R. H., 1986. Organizational Information Requirements: Media Richness and Structural Design, Management Science, 32, 4, pp. 554-571. Galbraith, J., 1974, Organization Design: An Information Processing View, Interfaces, 4, 3, pp. 28-36. Graetz, J. M., Creative Computing Magazine, August 1981 Pava, Calvin, Managing New Office Technology, The Free Press, New York, N.Y., 1983, p.58 Revkin, A., 2008. Dot Earth: ‘R2-D2’ and Other Lessons from Bell Labs, New York Times, Dec 12, 2008. Sabherwal, R., 2003. The evolution of Coordination in Outsourced Software Development projects: A comparison of Client and Vendor Perspectives, Information and Organization, 13 (3), pp. 153-202.
  11. 11. 11! Appendix 1: Methodology In the spring of 2010, we began our research with LVG Inc., and conducted initial scoping phone interviews with the General and Project Managers at LVG’s North American studios to select a specific project for case study. An on-site visit and interviews were then conducted in the late summer with 14 project team members in one of their facilities, including the General Manager, Project and Program Managers, Development Managers, Artists, Software Engineers, Creative Director, Audio Engineers, Outsourcing Managers, and Quality Assurance Managers. At two project milestones extending over two of their production runs, follow-up telephone interviews were conducted with the Program Manager, Development Managers, Outsourcing Manager, and Artists and Engineers, These interviews provided additional detail about the development process and team members’ perceptions of critical deliberations. For the final eight months of the GAME X 1 project, electronic surveys were administered to these team members at the end of each three-week cycle in their agile development process. An additional electronic survey was also conducted with five key vendor organizations located in Asia during a two-month period to assess how both parties to the virtual relationship viewed deliberation efficacy and how well potential challenges were met. An extensive interview was also conducted with a sixth vendor. Specific survey questions inquired about the frequency and mode of communication, key topics, roles of participants involved at both LVG and the vendor location, perceived effectiveness of communications and ratings of which factors (e.g. language, data transfer, etc.) may have been impediments and to what degree, and the nature of tasks (routine or non-routine) and their degree of completeness as performed by the vendors in each three-week development period. Follow-up phone interviews with Program and Development Managers were used to gain feedback on the survey results and on our preliminary analysis of deliberations in the development process, as well as to obtain an update on the final development stages and the results associated with release of the GAME X 1 product. During the autumn of 2011, detailed interviews were conducted with the Project and Program Managers, Outsourcing Manager, and Quality Assurance Manager, in order to learn the outcomes of their Game X 1 project debrief and related process innovations for work with key vendors for the development of the Game X 2 project. By January 2012, we received feedback in final interviews with the site LVG Managers, regarding the (mostly positive) impacts of the outsourcing process improvements made for Game X 2.

×