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